争议 | 银行一定要上分布式数据库吗？有没有其他技术路线满足需求？
以下内容来自社区探讨，欢迎点击阅读原文到社区与同行交流本话题
银行分布式数据库建设路径探讨，希望听听同行的看法
近来行领导听到非常多的人来沟通说分布式数据库如何好如何有价值，银行在分布式数据库的核心诉求究竟是什么？为什么一定要上分布式数据库？有没有其他的技术路线可以满足需求？如果上分布式数据库，需要避免哪些坑？希望能听听同行的经验和看法，让我们也能知道同行是如何想的。 （问题来自@pobird 系统架构师）
@岳彩波 产品经理：
一、采用分布式系统架构是由于业务需求决定的，若系统要求具备如下特性，便可考虑采用分布式架构来实现：
数据存储的分区容错，冗余
应用的大访问、高性能要求
应用的高可用要求，故障转移
二、 分布式系统遵循几个基本原则：
1、CAP 原理
CAP Theorem ， CAP 原理中，有三个要素：
一致性 (Consistency)
可用性 (Availability)
分区容忍性 (Partition tolerance)
CAP 原理指的是，在分布式系统中这三个要素最多只能同时实现两点，不可能三者兼顾。因此在进行分布式架构设计时，必须做出取舍。而对于分布式数据系统，分区容忍性是基本要求，否则就失去了价值。因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。对于大多数 web 应用，其实并不需要强一致性，因此牺牲一致性而 换取高可用性，是目前多数分布式数据库产品的方向。
从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。如果能容忍后续的部分或者全部访问不到，则是弱一致性。如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。
但 web 应用也有例外，比如支付宝系统，就要求数据（银行账户）的强一致性，而且面对大量淘宝用户，可用性要求很高，因此只能牺牲数据的分区冗余。这一点也曾在和支付宝工程师交流时，得到验证。
2.C10K 问题
分布式系统另一个理论是 C10K 问题，即系统的并发用户增加 1 万（ customer ten thousand ，过去一台服务器承载， 假设为 1 万用户，现在平均 3 ～ 5 万），是否意味着增加一台机器就能解决问题？答案通常是否定。
因为这涉及到系统的应用架构问题 ---- 串行系统和并行系统的架构和性能提升的关系：
串行系统一般设备越多，性能成一条向下弯曲的曲线，最差情况，可能性能不增反降；而并行分布式系统设备越多，性能是正比例线性增长的直线 3. 串行系统和并行系统的可靠性问题。
一个大系统一般都有超过 30 个环节（串行）：如果每个环节都做到 99% 的准确率，最终系统的准确率是 74%; 如果每个环节都做到 98% 的准确率，最终系统的准确率 54% 。一个 74% 的系统是可用的（有商业价值的），一个54% 的系统仅比随机稍好一点，不可用。这就是做大系统的魅力和挑战！
而以上描述只是各模块串行系统所遇到的问题，如果是并行系统，准确率 =1-(1-A)^B ，其中 A 是单个模块准确率， B 是并行模块个数。
如系统中每个模块的准确率是 70% ，那么 3 个模块并行，整体准确率 =1-0.3^3=97.3%, 如果是 4 个并行，准确率 =1-0.3^4=99.19%, 我在想这就是负载均衡靠谱的数学原理。5 个 9 或 6 个 9 的 QoS 一定是指数思维的结果，线性思维等于送死。
而对系统单一模块优化，准确性和可用性提升一个百分点，越接近 100% ，难度越大，投入成本越不可控（系统熵永不为零），因此可靠性系统必然选择并行分布式作为架构的基本方法。
@Amygo 数据库管理员：
1）银行在分布式数据库的核心诉求是什么？
回答：行里有安全可控的技术创新压力；也有业务转型的业务创新压力和合理控制试错成本。
2）为什么一定要上分布式数据库？
回答：创新就一定要控制试错的成本，及取得更大的行业影响力，要跟上时代的主流，避免技术路线上落后。
3）有没有其他的技术路线可以满足需求？
回答：不差钱的话，直接上IOE设备，实在不行就上AS400 或S390。
4）如果上分布式数据库，需要避免哪些坑？
回答：关键选对产品，选对厂商。产品一定要有生态链、行业应用案例和主流成熟的技术；厂商一定要专注做数据库产品研发和做到满足行里随叫随到的服务体验。
@孔再华 某银行 数据库运维工程师：
现在所有的大行都在实践分布式数据库。
分布式主要解决两个问题。一是性能扩展，弹性伸缩。单机数据库的处理能力是有上限的，尤其是纵向扩展有极限，也不能解决单库的瓶颈。分布式数据库的横向扩展几乎是唯一的解决途径。二是高可用性，单节点的异常不会导致整个集群的损坏，不会影响全局。异常节点的数据和任务能动态漂移，恢复时间短。
然而分布式数据库也存在很多挑战，并不是那么容易实现。分库分表对应用是否透明？如果从应用角度就开始分，合理开发应用，对于性能来说是最好的方式，但是需要很高的设计开发成本。如果对应用透明，完全由数据库来做，那么性能可能会成为问题，因为应用会存在跨库事务，存在两阶段提交等。分布式事务是否支持? 我们会看到接触的大多数分布式产品都支持，然而性能呢，都是问题。在测试的很多分布式数据库，都存在gtm这样的设计，用来协调数据库节点的事务。测试过程中，性能的瓶颈也基本出在这个核心功能上。
因此在上分布式数据库的时候，一定要关注这些点。挑选合适自己的数据库。从性能、高可用、管理性等方面全面评审才行。
@508mars 某证券 数据库管理员：
核心诉求我觉得有以下几个：
1）一些数据库越来越大，访问量越来越高，单机已经无法承载，或者纵向扩容的成本太高，这时候就需要通过支持横向扩展、支持廉价x86服务器的分布式数据库技术来解决。
2）现在很多行都开始微服务以及数据中台的建设，如果采用传统数据库技术，数据库实例的数目将会非常恐怖，DBA的运维工作将会受到极大挑战，解决这个问题我们就需要一个既能很方便的弹性伸缩，又能资源隔离（多租户）的数据库来存储数据，很多分布式数据库都提供了这样的能力。
市面上的分布式数据库技术分为两个流派：
1）采用中间件的分库分表方案
分库分表方案在市面上使用很多，尤其在互联网。这种方案的优势是底层采用成熟的传统数据库，所以数据库层面比较稳定，缺点是对应用的侵入性比较强、限制比较多，同时运维非常不方便。
2）原生分布式数据库
原生分布式数据库对应用非常友好，在应用看来就是一个单库，无需关心分布式事务、数据存储在哪个节点等一系列问题，同时运维也非常方便。原生分布式数据库同时还提供了良好的弹性伸缩容能力、高可用甚至容灾能力，这也是业界对其比较看好的重要原因。当然目前原生分布式数据库的缺点也很明显：太年轻，与传统数据库相比无论从稳定性（主要指性能，发生bug的概率）和功能性上来说都有一定差距；对存储过程、外键、触发器等特性基本不支持。
需要避免的坑，我想到的主要有：
1）如果应用大量使用Oracle PL/SQL存储过程，迁移会很痛苦，个人不太建议拿这些系统做试点
2）分布式数据库一般都采用两阶段提交，因此效率上会不如单机数据库事务，为了提升两阶段提交的性能，有些数据库会采用乐观锁，乐观锁会出现一些跟悲观锁不一样的行为，因此应用逻辑可能需要调整来适应。
3）在分布式数据库上跑中间结果集很大但最终结果集很小的查询效率可能不太好，主要是跨节点传输大量数据导致耗时较长，而传统数据库顶多就是从磁盘到内存这个过程，没有网络IO。
4）分布式数据库和传统数据库之间如何做容灾的问题，比如分布式数据库作为主库上线运行了，但是我们担心它会出问题，想利用传统数据库做备库，两者之前的数据同步如何进行，这目前也是我们想要解决的事情。
@杨建旭 银行 技术经理：
为什么一定要上分布式数据库？
--业务量大了，必须要分库分表。
如果上分布式数据库，需要避免哪些坑？
--如何分库分表要根据自己业务、技术能力来做。x轴拆分（水平复制数据库）、y轴拆分（按功能分）、z轴拆分（按用户分）。
@Aero 某银行：
关于诉求和为什么一定要上分布式数据库，不想多说，因为这些问题是仁者见仁智者见智的问题，近期我们做了一些分布式数据库的验证测试工作，其中还是碰到很多问题的，通过测试，发现分布式基础问题21个，分布式和Oracle兼容性问题28个，分布式和应用兼容性问题2个，分布式性能问题8个，以上问题都的到了厂商的确认，并进行了底层的修复。发现以上问题，都是通过大量的业务测试、场景测试和压力测试发现的，并进行了分析提交BUG修复。因此所谓的坑不是能避免的，而是要通过大量的测试去发现BUG，解决BUG，才能避免上了生产后踩坑。
目前我们通过认真讨论，也制定了大量异常场景进行破坏性测试，例如硬件问题场景、网络问题场景、业务问题场景（异常SQL）及极端场景进行了测试，通过以上大量的测试，技术人员自行编制了健康检查和健康巡检方案、慢查询SQL优化指南、分布式数据库异常问题解决案例手册、各异常场景测试报告及处理方案及总体测试报告等文档。
所以我们认为一个好的数据库是用时间、应用场景磨合出来的，只是我们在走之前Oracle、Db2已经走过的磨合道路罢了。
@wanglaye 金融机构 技术经理：
银行传统数据库在应对互联网金融场景时遇到了明显瓶颈，在面临交易复杂度和交易频率的大幅提升时，传统数据库能够采取的优化方案非常有限，若仅依靠软硬件升级来提升性能的话，成本非常昂贵。另外，在应对双十一这类特殊交易日时，需要在短期内提升数据库的能力，传统数据库缺乏这方面的灵活性。若仅仅为了应对有限特殊日的流量，而配置很高的性能，又会造成资源的极大浪费。基于能力、可控、弹性、成本等方面的考虑，引入具有高可用、高性能、高可扩展性的分布式数据库成为优先选择方案。
分布式数据库设计阶段需要考虑很多方面，比较重要的像是高可用方案、存储方案、灾备方案、安全、监控、运维等，这些在前期都要规划好。还有一点很重要，分布式数据库最终是为应用服务的，要充分考虑应用从传统数据库迁移至分布式数据库的难度，尤其在测试阶段，要充分考量分布式数据库的兼容性。
在分布式数据库选型时，最好结合具体的应用场景，如OLTP和OLAP。另外，数据库厂商的技术服务支持能力和案例成熟度也要充分考虑。
以上是本人的一些小经验，供大家讨论。
@刘诚杰 数据库管理员：
一、分布式数据库能解决什么问题？
首先，分布式数据库主要用于解决单机存储上限的问题。如今每天产生各类的数据量非常巨大，如果使用传统方案，要么不便于管理，要么成本过大。
其次，分布式数据库可以一定程度分散单节点数据库压力，如读写分离、多节点并行运算等。
最后，某些分布式数据库有多数据中心方案，可以以较低的成本实现数据库层面的多活方案。
二、银行在分布式数据库有什么核心诉求？
主要还是看用在什么业务场景，不同的分布式数据库有不同的优缺点和适用场景。
三、为什么一定要上分布式数据库？
大多数情况是因为单机无法满足存储或性能要求，参考第一问。
四、有没有其他的技术路线可以满足需求
公司研发团队自行编写中间件，可以满足需求，只是对研发能力要求较高，需要考虑到各类所需的场景。目前有不少大型互联网公司有采用此方案。
五、如果上分布式数据库，需要避免哪些坑？
1、出于稳定性考虑，最好用官方原始的分布式方案，谨慎选择使用第三方中间件。
2、因为分布式技术要求较高，建议有专人或者供应商进行维护。
3、使用主流的且经过时间考验的分布式方案，某些厂商为了分布式而分布式反而有不少问题。
4、对研发进行相关使用培训，否则性能损耗明显。
5、分布式架构时，某些特性会不支持，需要提前调研。
6、分布式场景下一致性的备份是个难点，不同数据库有不同解决方案。
7、重要数据各分片节点至少有2份或以上冗余，避免数据丢失
@韩成亮 数据库管理员：
看了上面说的很多，其实讲到底，还是场景问题，核心诉求是满足压力其次考虑现在的瓶颈问题，或者将来可能遇到的瓶颈问题，此外没有一点要上分布式数据库的说法，这个还是看你们的大致的规划和相应的投入，然后就是分布式讲究的AP/TP 分离或者混合部署，当然混合的往往的来自于业务的耦合情况，根据分布式的基本整体架构，目前的趋势是 计算、存储、调度，各个厂商都有各自的产品，需要进行对应的POC测试，只要经过POC测试才能准确的知道哪些坑，不能一概而论。
欢迎点击文末阅读原文到社区讨论交流，发表您的观点 觉得本文有用，请转发或点击“在看”，让更多同行看到
资料/文章推荐：
分布式数据库的场景选型和趋势分析解读
http://www.talkwithtrend.com/Document/detail/tid/428347
分布式数据库产品关键功能技术探索
http://www.talkwithtrend.com/Article/245341
欢迎关注社区 “数据库”技术主题 ，将会不断更新优质资料、文章。地址：http://www.talkwithtrend.com/Topic/597
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”
*本公众号所发布内容仅代表作者观点，不代表社区立场